fix(acp): spawn prompt turn to prevent permission-gate deadlock - #6660

Summary

• handle_prompt awaited the entire agent turn inline inside the ACP SDK's on_receive_request callback, holding the SDK's strictly serial dispatch loop for the whole turn. Since that same loop demultiplexes inbound RPC responses, the IDE's reply to a permission-gated tool call's session/request_permission request could never route back while the loop was blocked — deadlocking indefinitely (fail-closed, not a permission bypass).
• Fix: the turn now runs inside cx.spawn(...), responding to the session/prompt RPC request from the spawned task instead of the handler, per the SDK's documented ordering contract. This frees the dispatch loop to keep routing inbound messages, including the permission reply, while the turn runs.
• The fix's blast radius is broader than the issue title: every send_request(...).block_task().await from a per-session spawned task (fs.rs, terminal.rs, lsp/acp_provider.rs, agent/elicitation.rs) shared the same deadlock class and is fixed at the root by this change, though only the permission.rs path is regression-tested directly.
• The spawned task's tail is infallible by construction (matching the existing spawn_cancel_request_bridge convention in the same file): a respond/respond_with_error failure is logged and swallowed rather than propagated, since an Err returned from a spawned task tears down the entire connection per the SDK's contract, and a failed response send is a symptom of an already-closing connection, not a defect in the completed turn.

Known behavior change

"prompt already in progress" was previously unreachable from ACP because the blocked dispatch loop serialized session/prompt dispatch. It is now reachable if a client pipelines two prompts on the same session before the first completes — such a client now gets an internal_error instead of implicit queueing. Spec-conformant clients don't do this.

Follow-up (not in this PR)

do_prompt restores output_rx only on its success path; a pre-existing (not introduced here) input_tx.send failure early-return leaks it, permanently wedging the session. This is now slightly more observable given the behavior change above. Will file a dedicated follow-up issue.

Closes #6656

Test plan

• Added permission_gated_prompt_round_trip_does_not_deadlock (approve path) and permission_gated_prompt_denial_does_not_deadlock (deny path, fail-closed) integration tests, both timeout-guarded so a regression fails fast.
• Verified the new tests actually catch the bug — swapped in pre-fix prompt.rs, both tests failed with Elapsed(()), restored the fix.
• cargo +nightly fmt --check clean
• cargo clippy --profile ci --workspace --all-targets --features "desktop,ide,server,chat,pdf,scheduler,testing" -- -D warnings clean
• cargo nextest run --config-file .github/nextest.toml --workspace --features "desktop,ide,server,chat,pdf,scheduler" --lib --bins — 15098 passed, 0 failed, 36 skipped
• Rustdoc gate (RUSTFLAGS="-D warnings" RUSTDOCFLAGS="--deny rustdoc::broken_intra_doc_links" cargo doc --no-deps --workspace) clean
• gitleaks protect --staged clean